Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@custom_components/plugwise/manifest.json`:
- Line 11: The plugwise dependency URL in the manifest.json contains an extra
forward slash in the git reference syntax. In the string starting with
"plugwise@git+https://github.com/plugwise/python-plugwise.git/@water_heater_2",
remove the forward slash that appears between ".git" and "`@water_heater_2`" so
the URL follows the correct PEP 508 VCS format:
git+https://github.com/plugwise/python-plugwise.git@water_heater_2.
- Around line 10-12: The git requirement URL for the plugwise package in the
requirements array contains a malformed reference syntax with an extraneous
forward slash. In the plugwise requirement string that starts with
"plugwise@git+https://github.com/plugwise/python-plugwise.git/", remove the
forward slash immediately before the @ symbol so that it reads
"plugwise@git+https://github.com/plugwise/python-plugwise.git@water_heater_2"
instead. The @ symbol must attach directly to .git without an intervening slash
for pip to correctly resolve the git branch reference.

In `@custom_components/plugwise/number.py`:
- Around line 110-120: The issue is that self.ctrl is cached once during
initialization, causing the native_value property to return stale data after
coordinator updates. Instead of caching self.ctrl as an instance variable in the
initialization block, remove that line and modify the native_value property to
read directly from the current device state each time it is called by accessing
self.device.get(description.key, {}).get("setpoint"). Keep the initialization of
_attr_native_max_value, _attr_native_min_value, and _attr_native_step since they
define static bounds, but ensure native_value always fetches the fresh setpoint
from the device payload.

In `@custom_components/plugwise/translations/nl.json`:
- Line 307: The "off" label in the Dutch translation file (nl.json) currently
has the English value "Off" instead of the proper Dutch translation. Replace the
value "Off" with the Dutch translation "Uit" for the "off" key to maintain
consistency with other Dutch state labels in the file.

In `@custom_components/plugwise/water_heater.py`:
- Around line 109-110: The OPERATION_MODE feature is being advertised for all
water heater entities regardless of whether they actually have mode options
available. For entities like boiler_temperature where options_key is None, the
OPERATION_MODE feature should not be added to _attr_supported_features. Gate the
addition of WaterHeaterEntityFeature.OPERATION_MODE by checking if the entity
has valid mode options (i.e., options_key is not None) before setting it in the
feature flags. Apply this conditional gating consistently across all water
heater entity classes to prevent invalid mode-control paths.
- Around line 105-112: Remove the caching of `self.dhw_temp` at initialization
and instead use `description.key` dynamically to access per-entity temperature
data. Replace the line that sets `self.dhw_temp = self.device.get(DHW_TEMP, {})`
with direct references to `self.device.get(description.key, {})` when reading
UPPER_BOUND and LOWER_BOUND temperature limits. Apply this same pattern change
to the other affected areas (lines 122-123, 138-140, and 152) to ensure each
entity reads its own temperature configuration key dynamically rather than
caching stale data from initialization.

In `@tests/components/plugwise/snapshots/test_water_heater.ambr`:
- Around line 8-13: The boiler water-heater snapshots in the test file are
validating DHW-derived limits and modes instead of boiler-derived values, and
they contain an inconsistent mode contract where operation_list only contains
"on" while operation_mode or state is set to "eco". Update all affected snapshot
sections (including the ones at the specified line ranges) to use boiler-derived
temperature limits and operation modes, and ensure the operation_list values are
consistent with the actual operation_mode and state values being tested so that
the snapshots accurately validate the boiler entity behavior and catch any
mapping regressions.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@custom_components/plugwise/translations/nl.json`:
- Around line 100-106: The select_dhw_mode translation is incomplete: only
comfort and eco are defined in the select state map. Update the translation
entries for select_dhw_mode in the nl.json select section to include every DHW
mode the device can expose, such as anti_freeze, boost, and off, so the UI has
localized labels for all dynamically populated options.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@custom_components/plugwise/water_heater.py`:
- Around line 45-59: Remove the leftover developer note from the
WATERHEATER_TYPES definition in Plugwise water_heater.py; the inline “Upstream +
is there a reason we didn't rename this one prefixed?” text is an unresolved
review question, so either rename the related BOILER_TEMP/DHW_TEMP identifiers
consistently if that was the intended change or delete the comment entirely and
keep only the entity description declarations.
- Around line 116-118: Simplify the redundant operation-mode staging in
WaterHeaterEntity by removing the shared mutable cache used for on/off
branching. In async_set_operation_mode, async_turn_on, and async_turn_off, stop
relying on _mode_off, _operation_mode, and _list_type to decide the final
command, and instead derive the DHW mode directly from the requested operation
mode before calling set_dhw_mode. Keep async_turn_on and async_turn_off only as
thin wrappers if needed, but eliminate the extra state bookkeeping so the
behavior is driven by the current request rather than stale instance fields.